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Abstract. The well-known problem of state space explosion in model 
checking is even more critical when applying this technique to program- 
ming languages, mainly due to the presence of complex data structures. 
One recent and promising approach to deal with this problem is the con- 
struction of an abstract and correct representation of the global program 
state allowing to match visited states during program model exploration. 
In particular, one powerful method to implement abstract matching is to 
fill the state vector with a minimal amount of relevant variables for each 
program point. In this paper, we combine the on-the-fly model-checking 
approach (incremental construction of the program state space) and the 
static analysis method called influence analysis (extraction of significant 
variables for each program point) in order to automatically construct 
an abstract matching function. Firstly, we describe the problem as an 
alternation-free value-based /i-calculus formula, whose validity can be 
checked on the program model expressed as a labeled transition system 
(Lts). Secondly, we translate the analysis into the local resolution of 
a parameterised boolean equation system (Pbes), whose representation 
enables a more efficient construction of the resulting abstract matching 
function. Finally, we show how our proposal may be elegantly integrated 
into Cadp, a generic framework for both the design and analysis of dis- 
tributed systems and the development of verification tools. 



1 Introduction 

One of the most exciting challenges in the model checking community is to apply 
automatic reachabihty based verification to standard programming languages. 
Actually, there are many ongoing projects oriented to adapt the results on for- 
mal method research to languages like Java (see Bandera and Jpf |2]) or 
C/C++ (see Verisoft [HI, FeaVer (THj or SocketMC 0). As expected, a 
common problem to these approaches is how to deal with the state space explo- 
sion problem, resulting from the size of data structures employed in real software, 
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which is several orders of magnitude superior to the size of models written with 
formal description techniques. 

Abstract interpretation is one well-established solution to automatically con- 
struct smaller and sound models, which may be analyzed by model checking tools 
(see (7 16il2t3) '). This method, employed in tools hke Jpf, Bandera or aSPiN, 
is partial, because it consists in constructing an over-approximation of the pro- 
gram, where non-realistic paths are possible. Here, we are interested in a more 
recent approach, which tries to solve the problem using precise abstractions. 
Thanks to a minimal amount of information, such a method explores exactly 
the paths required for a given property. One technique of particular interest is 
abstract matching. It consists in using a function for reducing the state vector by 
ignoring variables, whose values are not relevant to check the property. Actually, 
these variables are temporally replaced by their abstractions, allowing to cut the 
exploration paths. Moreover, this approach generates an under-approximation 
of the whole state space. Thus, it never produces non-realistic paths. Holzmann 
and Joshi were the first in [HI to propose the technique, then employed in |26| 
and [S]. One novel contribution in [5] is the use of static analysis algorithms 
to automatically construct abstraction functions. The method makes use of the 
property to be analyzed, and in practice, it is based on computing the influence 
graph for each program variable. 

In this paper, we intend to automatically construct abstract matching func- 
tions by performing the influence analysis described in [5] using model checking 
techniques. The idea of using model checking to implement static analysis was 
first expressed by Steffen in |29) , who provided a framework to characterize data 
flow analyses as the verification of particular modal formulas. Schmidt then 
extended Steffen's work in |27| to relate it with abstract interpretation. More 
recently, the tool jABC |2J| put in practice Steffen's proposals in the context of 
Java programs. Our approach is close to these previous works, but rather focus 
on one specific analysis: influence analysis. We show how influence analysis can 
be expressed as an alternation-free modal ^-calculus formula with data param- 
eters evaluated on a labeled transition system (Lts) expressing the abstracted 
program behavior. Another interesting contribution of the paper is the encoding 
of influence analysis in terms of Boolean Equation Systems (Bes). Bess allow a 
natural description of numerous verification problems, such as model checking of 
temporal formulas, bisimulation, partial order reduction, horn clause resolution, 
abstract interpretation and conformance test case generation Moreover, 
Bess are efficiently supported by different resolution algorithms in the litera- 
ture, one implementation being the CiESAR_SOLVE library [25, which is part of 
the widespread verification toolbox Cadp This resolution library is used 
by the model checker E VALUATOR 3.5 [SJ, but also by bisimulation and partial- 
order reduction tools. In addition, it has recently been extended with distributed 
algorithms, thus allowing an immediate distribution of each tool connected to 
CiESAR_SOLVE ^U]. Hence, our static analysis proposal can directly benefit from 
this verification platform. Parallelly, the SocketMC tool is now being rewritten 
for Open / C^sar (the new tool being called C2Lts) , thus creating a complete 
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set of tools to perform the whole cycle towards verification of software with 
abstract matching functions. 

This paper is organized as follows. Section |21 summarizes the influence analy- 
sis algorithms used to construct abstract matching functions. Section|31translates 
the different algorithms into alternation-free /i-calculus formulas with data pa- 
rameters, and explains the limitations of such an approach. Section 0] further 
transforms the problem into Pbes resolutions. Section O shows how to exper- 
iment the different encodings into the verification toolbox Cadp. Finally, Sec- 
tion Ogives some concluding remarks and directions for future work. 

2 Influence analysis for abstract matching 

As proposed in JT], an abstract matching function f () should be invoked when 
it is necessary to compact the state vector. In such cases, the abstraction function 
computes abstract representations of the hidden data and copies the result onto 
the state vector. In ^7], the authors do not address any particular method to 
generate f ( ) , however they present necessary conditions to define sound abstract 
functions that preserve Ctl properties. 

In |S] a particular method is proposed to construct f ( ) in such a way that 
the function be sound and oriented to the property to be checked. This method 
is based on the identification of variables that influence the verification result 
from the current state. In particular, the authors of |S] developed the so-called 
influence analysis (lA) to annotate each program point p with the set of sig- 
nificant variables IA(p) needed to correctly analyze a given property. Data flow 
analysis I A is a variant of the classic live variable analysis (LV) that attaches 
each program point with the set of live variables at this point. The key differ- 
ence is that lA makes use of the property to be checked to determine the set of 
needed variables. Informally, a variable is needed (w.r.t. lA), if its current value 
may be necessary to evaluate the property of interest in the future. Thus, at a 
given point, a live variable (w.r.t. LV) may not be needed, if its value does not 
influence the evaluation of the property. 

For each program point p, \A{p) is iteratively calculated as the fixed point 
of an operator that informally works as follows. Let V be the set of program 
variables. lA starts by attaching to p the set I{p) C V of variables, which are ini- 
tially needed at p. The definition of I{p) depends on the property to be analysed. 
Now, assume that it is known that variable x G V is needed at point p, then 
variable y £ V influences x at p, if there exists an execution path in the program 
from p to an assignment x = exp, and the current value of y is used to calculate 
exp. The notion of influence is recursive since it may be necessary to check if y 
influences some variable appearing in expression exp in order to decide whether 
y is needed at point p. As shown in the following sections, a consequence of this 
recursive behaviour is that we need to use parameters when translating lA into 
/x-calculus formulas or boolean equation systems. 

Influence analysis is used in a dual manner by hiding (abstracting) the vari- 
ables, which are not needed at each program point, while the rest of variables 
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remains explicit in the state vector. Therefore, the best lA analysis is the one 
attaching the smallest set of variables to each point. 

The work in |S] describes four different influence analyses preserving specific 
properties. The most precise analysis, denoted as lAi, only preserves information 
on reachable code. As an example, we can consider the C process pi, shown in 
Figurcn(a). The goal of lAi is to determine, in each program point (represented 
as labels Lq,--- , L4 in process pi, and vertices in the corresponding control 
flow graph illustrated in Figure ^(b)), which variables will affect the program 
execution flow. 




(a) H (b) H 

Fig. 1. Example of a C program pi (a) and its control flow graph (b) 

Figuren(b) shows the intended result of lAi for pi. For this process, the static 
analysis associates the set {x} with the labels LO, LI, and L2 (represented in the 
control flow graph as nodes 0, f and 2). Hence, if we are interested in knowing 
whether a particular label of process pi is reachable, we only have to store 
variable x at labels LO, LI, and L2. In particular, variable y may be completely 
hidden because its value is not relevant for this analysis. 

The other variants of lA extend lAi in the following way: IA2 produces bigger 
sets of variables, but it preserves safety properties. It extends lAi considering 
variables contained in assertions; IA3 studies the case of models with global 
variables; IA4 is the least precise analysis, but in contrast, it preserves liveness 
properties. It is based on considering as influencing variables all variables ap- 
pearing in the temporal formulas to be verified. More details on these influence 
analyses can be found in . It is worth noting that they can be directly applied 
to different kinds of modelling and programming languages. In particular, in the 
rest of the paper, we assume concurrent systems written in C code. 

3 Mu-calculus model checking for influence analysis 

This section is devoted to the model-checking of influence analysis over finite 
Ltss. We first define the Lts model extracted from the program being statically 
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analysed, next we describe how the influence analysis problem can be translated 
into the model checking of temporal formulas over the program model, and finally 
we give the limitations of such an approach. 

3.1 Presentation of the program model 

Influence analysis takes as input a program, or more precisely, a model extracted 
from it. In this work, we consider the Labeled Transition System (Lts) model, 
which is suitable for value-passing languages, in particular for concurrent system 
descriptions. An Lts is a tuple {S, A,T, sq), where: 

— 5' is a finite set of states; 

— A is a finite set of actions. An action a G Ais represented as a list iw, where 
i identifies the type of actions and ii; is a list of typed values; 

— TC5'x^x5'is the transition relation. A transition (s, a, s') e T, also 
noted s A s', states that the system can move from s to s' by executing 
action a {s' is an a-successor of s); 

— So G is the initial state. 

Furthermore, with respect to the influence analysis problem, we are mainly 
interested in the set of program variables, that are present in program expres- 
sions, such as boolean and assignment expressions. Thus, we will use only one 
type of value, for instance the type Var denoting the set of program variables, 
and we define two types of actions being present in Lts labels: 

— BOOL V describes a boolean expression based on the list of variables v of 
type Var; 

— ASSLGN vi.v describes an assignment expression, where variable vi of type 
Var is assigned a value based on variables v. 

Example 1. Using the research work of |6ll3j . which focuses on extracting Ltss 
out of C programs using well-specified Apis, we can construct an Lts (see Fig- 
ure 121) corresponding to the program presented on Figure Q 




Fig. 2. Example of Lts extended with special actions BOOL and ASSIGN 
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Its construction results from the control flow analysis of the program to- 
gether with a labelling of relevant (i.e., BOOL and ASSIGN) and invisible 
(i.e., r) actions. Moreover, our model splits each action "BOOL vi, . . . , vj" in 
actions "BOOL v " containing only one variable Vi, for all i € [1, j]. Similarly, 
each action "ASSIGN vi V2 ... w/' is split in actions "ASSIGN vi w^" with 
two variable parameters only, for all i S [2,j]. We can also remark that non- 
determinism may be introduced artificially (i.e., actions "BOOL x" from state 
0) when creating the Lts. However, since the unique purpose of such an Lts is 
to enable influence analysis, all pertinent information for the analysis is kept. 
Consequently, the static analysis will still have a unique solution. 

3.2 Influence analysis using formulas with data parameters 

Modal /x-calculus [201 is an expressive temporal logic based on fixed points, 
that allows to express a wide range of properties on Ltss, including those of 
various other useful logics, such as Pdl or Ctl ^ (as well as its action- 
based extension AcTL pSjl. 

The alternation- free fragment of the modal /i-calculus, noted [S], is ob- 
tained by forbidding mutual recursive dependencies between minimal and max- 
imal fixed point variables. This logic is of practical usefulness thanks to the 
existence of linear resolution algorithms in the size of the formula (number of 
operators) and Lts (number of states and transitions). 

In this work, we are interested in the value-based extension of the logic j2Sl, 
which enables the specification of data variables and parameterised fixed point 
into the temporal formulas. Properties are not restricted to static label descrip- 
tion, but they can refer to dynamic values dependent from the system execution. 
Formulas of alternation-free value-based modal /i-calculus are defined by the fol- 
lowing grammar (where X ^ X is a propositional variable, and X a set of 
propositional variables): 

(p ::= false | true | (^i V ^2 | ^1 A 02 | {o) <t>\ Wi I X{e) 
I ^X{x ; t ;= e).(/) | i^X{x : t := e).0 

The semantics of a formula 4> over an Lts M = {S, A,T, sq) denotes the 
set of states satisfying and it is defined as follows: boolean operators have 
their usual definition; possibility operator (a) (resp. necessity operator [a] 4>) 
define states from which some (resp. all) transitions labeled by action a lead 
to states satisfying formula 4>; propositional variables X are parameterised by 
data variables e; minimal (resp. maximal) fixed point operator iJ,X{x : t := 
(resp. iyX{x : t := e).(j)) denotes the least (resp. greatest) solution of the fixed 
point equation X{x : t) = (j)^ parameterised by data variables x and argument 
types t, evaluated with the arguments e and interpreted over 2'^. On-the-fiy 
model checking determines if the initial state sq of an Lts satisfies a formula ^ 
and belongs to the set of states denoted by (j). 

Influence analysis is a static program analysis process that it is intended to 
extract from a specification the set of variables influent on the property evalua- 
tion for each program control point. Although it is a fragment of the data flow 
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analysis problem, which has been shown to be solvable using model checking 
techniques |2H1, namely using the modal ^-calculus, there doesn't exist to our 
knowledge a value-based Lj^ formula encoding the problem of influence analysis. 
Our approach is the same in spirit to the one of |f2Tj , where checking a program 
property corresponds to writing a new formula, evaluating it on the model and 
extracting from the set of states satisfying the formula, those defining the differ- 
ent program points. Considering that influence analysis algorithm lAi from [S] 
attaches each program point with the set of variables, whose value is needed to 
preserve the reachability graph, the resulting value-based formula is: 

^lAi = fiY{v : Var := x). ( (BOOL v) true 

V {ASSIGN z : Var v) Y{z) 

V {^{ASSIGN V z : Var)) Y{v)) 

Similarly, algorithms IA2-4 can be encoded as a /^-calculus formula. Since 
algorithm IA2 relies on assertions present in the program, it is necessary to 
extend our Lts with a new type of label: 

— ASSERT V describes an assertion composed of variables v of type Var. 

(/)iAi can naturally be extended by taking into account assertion variables and 
we obtain the following formula: 

= ^iY{v : Var := x). ( {BOOL v) true 

V {ASSERT v) true 

V {ASSIGN z : Var v) Y{z) 

V {-^{ASSIGN V z : Var)) Y{v)) 

Algorithm I A3 being an extension of lAi and IA2 considering not only local 
variables but also global variables, the encoding of the problem as a /x-calculus 
formula is unchanged and does not need an extra definition. However, algorithm 
IA4 aims at preserving generic temporal properties, and for this purpose, all vari- 
ables included in such a property have an influence over the program execution. 
Since the information contained in temporal properties is external to the pro- 
gram being checked, it will not be accessible in its extracted model, described 
as Lts. Hence, checking the influence IA4 of a variable a; at a specific program 
point is equivalent to, first, test the inclusion of x in the set of variables used in 
the temporal properties, then, if x is not included, evaluate (f>\/\^ on the Lts as 
follows: 

(^iA4 = fiY{v : Var := x). ( {BOOL v) true 

V {ASSIGN : Var v) true 

V {ASSIGN z : Var v) Y{z) 

V {-^{ASSIGN V z ■ Var)) Y{v)) 

The formula 4>\i\i is an extension of 0iai with as many modal operations 
{ASSIGN Wi : Var v) as variables Wi present in the external temporal property. 
Indeed, if a variable v affects the value of Wi in the program, then v is an infiuent 
variable itself. 
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Example 2. To illustrate the use of model checking /i-calculus formulas for in- 
fluence analysis, we can show the result of evaluating on the Lts given in 
Example Q Checking the validity of (/)|Ai for variable x on state sq will return 
true, since there exists boolean expressions (e.g., ^^BOOL x") involving x reach- 
able from So- This process can be iterated through all states figuring in the Lts 
and all variables of the program (i.e., x and y), allowing the progressive con- 
struction of the list of variables influencing each state (see Figure |3J). We can 
remark that only x influences part of the Lts. Hence, variable y can be totally 
disregarded without involving any skip of reachable states. 




Fig. 3. Example of influence analysis using /i-calculus model checking 



3.3 Limitations of using on-the-fly value-based model checking 

Instead of iterating through each state, in order to obtain all states satisfying (/)|Ai 
for a given variable, it would be more convenient to evaluate only one formula 
on the whole Lts, and consequently to extract a subgraph from the original Lts, 
containing all states influenced by the specific variable. This could be done by 
computing (/)|Ai on the Lts in a backwards manner using a fixed point iteration. 
However, this requires the prior computation of the Lts, and we seek a solution 
which is suitable for on-the-fly exploration. An adequate /i-calculus formula (for 
lAi) would look like the following: 

0a/;iAi = I'Z. ( 0iAi A [ true ] ( ^ (^iai V Z ) ) 

This formula has the same interpretation as (/)|Ai , meaning that its satisfaction 
on the initial state sq denotes that the given variable is significant for the initial 
state. Moreover, the on-the-fly evaluation of (/>a/;iAi on a state satisfying (j)\f^^ 
requires the recursive evaluation of all its successors that also satisfy <f)\i\^ , until 
all states satisfying ^ia^ have been explored. In case of a true answer, it is then 
possible to draw a positive diagnostic (example), that only reports the states 
annotated by x in the FigureOl However, this is only true if a: never gets assigned 
a new value. In such a case, this might create holes in the diagnostic, as can 
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be shown in Figure |31 when adding an artificial new state 55 connected to sq. 
Evaluating (f>aU\Ai on S5 will return false for variable x, whereas x is influent 
on states sq, si and S2- Standard model checkers are not designed to draw 
such a diagnostic or a partial one with only states satisfying ^ia^ . Hence, an 
iteration through all states is necessary to incrementally construct the set of 
states influenced by a speciflc variable. 

Working at the level of /^-calculus formulas and standard model checkers, 
allows to design generic solutions that work not only for influence analysis but, 
more generally, to many static analyses including data flow analyses |21| . How- 
ever, using on-the-fly model checking presents limitations such as the reusability 
of formulas validity for different states given a variable, in order to use previous 
computations to faster the check of new explored states and variables. In this 
sense, global model checking would be more appropriate, but is more prone to 
state space explosion when generating the complete state space and verifying 
the formula on each of its states. Moreover, it would be more convenient to 
incrementally generate the list of variables that influence each state, in order 
to define strategies on which variables need to be checked on successor states, 
thus allowing a gain in the number of computations needed. To respond to these 
limitations, a finer-grained encoding of the problem in terms of Pbes resolution 
is preferred and it is described in the following section. 

4 Influence analysis using PBES 

This section introduces the Parameterised Boolean Equation System (Pbes) 
model, and gives a Pbes encoding of the influence analysis problem. 

4.1 Definition of a parameterised boolean equation system 

A Boolean Equation System (Bes) |ll22j is a tuple B = {x, Mi, . . . , Af„), where 
a; G A" is a boolean variable, X a set of boolean variables, and Mi are equation 
blocks {i £ Each block Mi = {xij = opijXij}j^j^i „ii] is a set of minimal 

(resp. maximal) flxed point equations with sign ai = n (resp. ai ~ v). Boolean 
constants false and true abbreviate the empty disjunction V0 and the empty 
conjunction A0 respectively. A variable Xij depends upon a variable xu if xu G 
Xij . A block Mi depends upon a block Mk if some variable of Mi depends upon 
a variable defined in Mk- A block is closed if it does not depend upon any other 
blocks. A Bes is alternation- free if there are no cyclic dependencies between its 
blocks. In this case, blocks can be sorted topologically such that a block Mi only 
depends upon blocks Mk with k> i. The main variable x must be defined in Mi. 
In this work, we are interested in the parameterised extension of alternation- 
free Bes Uni, called Pbes. A Pbes is a tuple B = {x {z : i), A/i, . . . , Af„), 
where x € X \s & boolean variable parameterised by data variables in z typed 
by t. Similarly, each block Mi = {xij{zij : Uj) = opijXij}i(z[i^„], jeli^m,] is 
parameterised by data variables in Zij typed by tij . 
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The semantics lop{xi{zi : ti), . . . ,Xk{zk ■ *fc)}]<5 of a formula op{xi{zi : 
ti), . . . ,Xk{zk '■ tk)} w.r.t. B = {false, true} and a context 5 : A" — > B, 
which must initiahze all variables xi, Xk, is the boolean value S{xi{zi : 
ti)) op ... op 5{xk{zk ■ tk))- The semantics |Af,;](5 of a block Mi w.r.t. a 
context S is the (T,;-fixed point of a vectorial functional 'Pig : B™' B™' de- 
fined as <Pisibi, . . . ,6,„J = (|op,yX.y]((50 [6i/a;,;i, . . ■ ,bmjximi]))je[i,nii], where 
6 [^i/xii, ■ • ■ ,bmi/xim..] denotes a context identical to S except for variables 
Xii , . . . , Ximi , which are assigned values hi, ... , brm , respectively. The semantics 
of an alternation-free Pbes is the value of its main variable x{z : t) given by the 
solution of Ml, i.e., 6i{x{z : t)), where the contexts 6i are calculated as follows: 
5n = iMjiJl] (empty context because M„ is closed), Si = (|Afi](5i+i) Si+i for 
i £ [1, n — 1] (interpretation of Mi in the context of all blocks Mk with k > i). 

The local (or on-the-fly) resolution of an alternation-free Pbes B = {x {z : 
t), Ml, . . . , Mn) consists in computing the value of x{z : t) by exploring the 
right-hand sides of the equations in a demand-driven way, without explicitly 
constructing the blocks. Several on-the-fly Bes resolution algorithms |ll22j and 
Pbes resolution algorithms |28I15) are available; here we consider both the ap- 
proach in giving an algorithm to solve alternation-free Pbes, and the ap- 
proach of jl], formulating the Bes resolution problem in terms of a boolean graph 
representing the dependencies between boolean variables. 

A boolean graph is a triple G ~ {V,E,L), where V — {xij{zij : tij) \ i G 
[1, n] Aj £ [1, rrii]} is the set of vertices (boolean variables with data parameters), 
E :V ^2"^, E = {xij{zij : Uj) -> Xki{zki : tki) \ Xki G Xij} is the set of edges 
(dependencies between variables), and L : V ^ {V, A}, L(xij{zij : tij)) = opij 
is the vertex labeling (disjunctive or conjunctive). An example of Pbes with one 
block {i ^ n = 1) and its associated boolean graph is shown on Figure 0] 



^xi,i{v) = xi,e{v) V xi^2{v) V xi^4{v) 
xi.,2iv) = Xi^3{v) 
Xl.,3{v) = Xi,i{v) 
xia{v) = Xl,5{v) 

xi,5{v) = false 
xifi{v) = true 




xia{v) 



portion explored during an 
on-the-fly resolution 



xi.iiv) 
V 



Xl,5{v) 

V 



(a) 



(b) 



Fig. 4. (a) Example of a parameterised boolean equation system, (b) its boolean 
graph and the result of an on-the-fly resolution for xi,i{v). Black and white 
vertices denote false and true variables, respectively. 
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The resolution of variable x{z : t) is performed by a joint forward explo- 
ration of the dependencies going out of x{z : t) with a backward propagation of 
stable variables (whose final value is determined) along dependencies; the res- 
olution terminates either when x{z : t) becomes stable (after propagation of 
some stable successors) or when the portion of boolean graph reachable from 
x{z : t) is completely explored. The truth value of x{z : t) can be accompanied 
by a diagnostic, which provides the minimal amount of information needed for 
understanding its computed value, as shown in the dark grey area on Figure^ 

4.2 Encoding of influence analysis as PBES resolution 

To solve influence analysis using Pbes resolution, the first step is to construct 
an adequate equation system. Following the approach of \2'6\ . it is possible to 
transform the problem of evaluating a value-based alternation-free ^-calculus 
formula upon an Lts, into the resolution of a parameterised modal equation 
system (Pmes) upon the Lts, by extracting fixed point operators out of the 
formula. Starting from (/)|Ai , the resulting Pmes contains one block of modal 
equations and it is given as follows: 

Y{v : Var) = ( {BOOL v) true 

V {ASSIGN z : Var v) Y{z) 

V {^{ASSIGN V z : Var)) Y{v)) 

Then, to obtain a Pbes each modal equation block is converted into a 
boolean equation block by 'projecting' it on each state of the Lts being checked: 

{Ys{v : Var) ^ V,A,s' | a^BOOL v ^^ue 

^VsAs' I a^ASSIGN z v {z) 
^Vs^s/ I a^ASSIGN v z ^s'(y)]s<^S 

A boolean variable Ys(v) is true iff state s satisfies the prepositional variable 
Y considering variable v. Thus, the on-the-fly influence analysis of variable x 
on the initial state of the Lts amounts to compute the value of variable Ys^ {x) . 
The resolution of variable Ygg (x) on the Lts given in Figure |21 is illustrated on 
Figure 01 where variable xi^i{v) corresponds to variable Ysg{x), and variables 
xij{v) are successors reachable from Ysg{x), w.r.t. the Pbes given above. As 
shown by the white color, meaning a true value, of node Xi^i{v), variable x is 
influent on state Sq. A diagnostic can further be constructed to justify this result 
by showing a boolean subgraph (in the dark grey area on Figure^)) containing the 
variables making xi_i{v) true. For instance, it shows variable xi^2iv), which is a 
{'^BOOL x") -successor of Xi^i{v), such a transition being the minimal condition 
for X to be an influence variable. 

Generalizing the approach, the influence analysis of all program variables x 
over all states s contained in the Lts, can be transformed into an iterative local 
Pbes resolution algorithm. 

The function Influence_Analysis, shown on Figure [SJ describes the in- 
fluence analysis of an Lts M = {S,A,T,so) using a Pbes resolution for each 
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1 

i 


InFLUENCE_AnALYSIS (S'j^jTjSo) 




o 
I 


visited := sq; explored :— 0; 




3 


while visited ^ do 




4 


s := get{visited); visited 


:= visited \ s; 


5 


explored •— exploredU s; 




5 


forall v G var{A) do 




7 


if solve{Ys{v)) then 




8 


d{s) ■-d{s)Uv 




9 


endif 




10 


endfor; 




11 


forall s' G succ{s) \ explored do 


12 


visited := visited U s' 




13 


endfor 




14 


endwhile; 




15 


return d 





Fig. 5. Influence analysis of Lts using Pbes resolution 



program variable (i.e., v{A)) and Lts state. It starts the resolution with initial 
state So (line 2) and iterates through each program variable v (lines 6-10) by 
constructing and solving the corresponding boolean variable Ysg{v) (line 7). If 
the variable v is influent upon the current state, then the set d{so) of influence 
variables for state so is increased with variable v (line 8). Next, the process con- 
structs the hst of successor states of sq (lines 11-13), and continues the analysis 
until aU states are explored (hne 3). The result of function Influence_Analysis 
is the function d : 5 — > 2'"^'^\ which returns for each state, the list of variables 
that are significant. Such a function d can be further used to automatically con- 
struct an abstract matching function stating which variables need to be inserted 
in the state vector at each program point. Finally, we can also remark that the 
algorithm presented on Figure |S1 can be applied with all influence analysis al- 
gorithms IAi_4 by using the corresponding Pbes encodings when constructing 
boolean variable Ys{v) (line 7). 

This solution is similar in spirit to the model checking specification in terms 
of /x-calculus formulas, as it allows to directly provides the desired property as 
an equation system, whereas it was expressed as a temporal formula in the previ- 
ous approach. An important aspect of the method is that influence analysis will 
require the resolution of only one structure, the parameterised boolean equation 
system, whereas it needed the resolution of as many /x-calculus formulas as vari- 
ables being checked, times the number of states in the Lts. Moreover, the Pbes 
is solved on-the-fly, which means that only the relevant parts of it are computed 
for each state and each variable. Finally, since a boolean variable Xij defined in 
Mi may be required several times during the resolution process, it is possible 
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to obtain an efficient overali resoiution by using persistent computation results 
between subsequent resolution calls. 

5 Implementation and experiments 

The model checker E valuator 3.5 |23 (see FigureE)) has been developed within 
Cadp 22 by using the generic Open/CjESAR environment fTUI for on-the-fly 
exploration of Ltss. The static analyser Annotator on FigurcOis a proposal of 
tool integrated to Cadp. that applies our Pbes approach and follows the same 
architecture of Evaluator 3.5. 



Open/C^SAR environment 




Fig. 6. The on-the-fly tools Evaluator and Annotator 

Evaluator {resp. Annotator) consists of two parts: a front-end, responsi- 
ble for encoding the verification of the formula {resp. the static analysis type) 
on LtSi as a Bes {resp. Pbes) resolution. Evaluator produces also a coun- 
terexample by interpreting the diagnostic provided by the Bes resolution; and 
a back-end, responsible of Bes {resp. Pbes) resolution, playing the role of veri- 
fication engine. Both tools are obtained by using, as back-end, algorithms of the 
CiESAR_SOLVE library [5^. Globally, the approach to on-the-fly model checking 
{resp. static analysis) is both to construct on-the-fly the LtSi and corresponding 
Bes {resp. Pbes) and to determine the final value of the main variable. 

In the sequel, we present an experimentation with Evaluator 3.5 of the 
influence analysis property lAi expressed as a modal equation system (Mes) 
that is not parameterised, and the structure of Annotator to achieve the static 
analysis of an Lts using Pbes resolution within Cadp. 
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5.1 Experiments with EVALUATOR 3.5 



The current E valuator model checker of Cadp, whose version is 3.5, does 
not handle data parameters in /i-calculus formulas. However it is possible to use 
EVALUATOR 3.5 with the /i-calculus formula 0iai , by transforming it in a param- 
eterless equation system. This can be done, assuming that the set of program 
variables Xi is known, by instantiating each call to Y{xi) into a parameterless 
propositional variable named Y^. . Moreover, to get a more compact representa- 
tion of the expanded formula, we can use modal equation systems (Mes), which 
are accepted as input for Evaluator 3.5 as .blk files (option -block). Such trans- 
formation has already been realized in Section 14.21 where the formula 0iai was 
expanded into a Pmes. In order to obtain a resolution complexity linear in the 
size of the Lts and Pmes, it is necessary to simplify the Pmes, by splitting each 
right-hand side equation in order to have a single boolean or modal operator )23| . 
Thus, simphfying the Pmes Y of Section IT^ leads to the following Pmes: 

Yi{vi:Var)^Y2MyY3{vi) 

Y2{v2 : Var) = (BOOL V2) true 

r3(z;3: Far) i^y4(«3)vr5(i>3) 

r4(w4 : Var) ^ {ASSIGN z : Var v^) Y{z) 

r5(u5 : Var) = {-^{ASSIGN z : Var)) ^(^5) 

Next, we transform the simplified Pmes in a Mes using the parameterless 
propositional variable YjjUi. This Mes has a size quadratic w.r.t. the number 
of influencing variables in the program, but this may be of reasonable size if 
the number of variables in the program is also not very large. The .blk file, for 
variables x and y in the Lts on Figure [3 is the following: 



block mu B is 
Yl_x = Y2_x or Y3_x 
Y2_x = < "BOOL x" > TRUE 
Y3_x = Y4_x or Y5_x 
Y4_x = < "ASSIGN y x" > Yl_y 
Y5_x = < not ("ASSIGN x y") > Yl_x 



Yl_y = Y2_y or Y3_y 
Y2_y = < ' 'BOOL y' ' > TRUE 
Y3_y = Y4_y or Y5_y 
Y4_y = < "ASSIGN x y" > Yl_x 
Y5_y = < not ("ASSIGN y x") > Yl_y 
end block 



Then, to evaluate the influence of variable x [resp. y) on the initial state 
So, we can use the .blk clause eval B:Yl_x {resp. eval B:Yl_y), which tells 
Evaluator 3.5 which propositional variable it has to check. As a consequence, 
another limit of the method using Evaluator 3.5 is that we cannot check the 
influence property on a state different from the initial state, as EVALUATOR 3.5 
will systematically evaluate the Mes on the initial state of the considered Lts. 

5.2 Implementation of an on-the-fly static analyser in CADP 

Instead of using a model checker, wc seek a solution that will explicitly manipu- 
late the encoded problem as Pbes, implementing the algorithm given in Figure|3 
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This led us to the need of constructmg a static analyser in Cadp, based on the 
Open/CjESAR interface for on-the-fly exploration of Lts. 

The architecture of such a tool, named Annotator, is described on FigurcEl 
For each visited state in the Lts, it computes the encoding of the static analysis 
problem in terms of Pbes and solves it upon the state following the algorithm 
in Figure |S1 In the case of influence analysis, the corresponding Pbes, given in 
Section can be projected to the Lts to generate a flat (i.e., parameterless) 
Bes, that would be solved by the CiESAR_SOLVE hbrary. Once the satisfiability 
of the static property has been computed, the tool can update the definition 
of a function that returns for each state the result of the analysis (i.e., a set 
of significant variables in the context of influence analysis). After exploring the 
entire state space, the annotating function is returned by the tool, and can be 
further used by other applications, e.g., for abstract matching. 

Another important feature of the tool is that both the extracted model (as 
Lts) and the Pbes can be constructed and explored on-the-fly, thus allowing 
incremental exploration of only the part of both graphs that is necessary to 
perform the static analysis. 

6 Conclusion and future work 

Static analysis is a necessary step towards software model checking with ab- 
stract matching. Our encodings of the influence analysis problem in terms of 
alternation-free ^-calculus formulas with data parameters and in terms of Pbes 
resolution enables to automatize the analysis process and to use it in conjunction 
with on-the-fly verification tools. To develop robust explicit-state analysis tools, 
it is necessary to use efficient and generic verification components. Our proposi- 
tion of on-the-fly static analyser Annotator goes towards this objective by rely- 
ing on the generic Open/C^SAR environment ^01 for on-the-fly Lts exploration 
within Cadp and by using the Bes resolution fibrary CjESAR_Solve pij . 

We plan to continue our work along several directions. First, we will fin- 
ish the construction of Annotator, as well as the translator C2Lts proposed 
in |13j and show the impact of automatic abstract matching on the explored 
state space size during verification. Next, we will study the interconnection of 
both tools integrated into Cadp with tools extending Spin, such as SocketMC 
and aSPiN ^^l- Finally, we will seek solutions to other static analysis problems, 
especially data fiow analyses already expressed as /i-calculus formulas in |27| , by 
investigating their translation in terms of Pbess resolution. 

Acknowledgements. We are indebted to Radu Mateescu for its valuable feedback 
on the possible interaction of our proposal with Cadp model checkers. 
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